home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000155_edrbtsn@cs.indiana.edu _Tue Jun 8 17:14:04 1993.msg < prev    next >
Text File  |  1996-01-31  |  5KB  |  94 lines
  1. Message-Id: <199306082214.AA05438@optima.CS.Arizona.EDU>
  2. Received: from bigeye.cs.indiana.edu by optima.CS.Arizona.EDU (5.65c/15) via SMTP
  3.     id AA05438; Tue, 8 Jun 1993 15:14:12 MST
  4. Received: by bigeye.cs.indiana.edu
  5.     (5.65c/9.4jsm) id AA10100; Tue, 8 Jun 1993 17:14:05 -0500
  6. From: "Ed Robertson" <edrbtsn@cs.indiana.edu>
  7. Subject: benchmark directions
  8. To: tsql@cs.arizona.edu (TSQL working group)
  9. Date: Tue, 8 Jun 1993 17:14:04 -0500 (EST)
  10. X-Mailer: ELM [version 2.4 PL21]
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=US-ASCII
  13. Content-Transfer-Encoding: 7bit
  14. Content-Length: 4495      
  15.  
  16. In response to Rick's invitation, the following are our observations
  17. on the purpose and nature of the "semantic benchmark."
  18.  
  19. Alex and Jim correctly state that 'the whole idea behind this "semantic
  20. benchmark" is to provide some measure of what should be expressible in a
  21. temporal query language.'  This statement has the right amount of
  22. flexibility.  We definitely want the ability to intuitively measure but
  23. need the "some" because we're not sure whether we'll be lucky enough to
  24. have a real metric.  The "should" is also important; it's not "must" but
  25. rather an indication of what's desirable.  Rick has extended their
  26. statement with an interpretation that the measure provides a "sound
  27. theoretical basis"; this may be too much to hope for.
  28.  
  29. Temporal databases require a different kind of benchmark, a benchmark that
  30. deals with meaning, because the entire motivation for this area is the
  31. specialized meanings we attach to time.  Other nascent specializations
  32. within databases deal with new kinds and representations of information -
  33. audio/video streams, multidimensional arrays, etc. - but temporal
  34. information maps reasonably to integers (albeit the "June 31st" problem)
  35. and relations (albeit fragmentation).  We deal with time specially because
  36. we want to capture the conceptual (and hopefully implementation)
  37. efficiencies related to the very particular semantics we use for this
  38. area.  Thus the issues of temporal databases are related to our thought
  39. and language.  But we are not linguists or philosophers; we have very
  40. specific interests in the development of useful and usable products.  We
  41. can therefore benefit by having ways of assessing the success of our
  42. products.  The meaning of "user-friendly" is therefore not the
  43. bells-and-whistles the purveyors of PC fluff use but rather the
  44. naturalness of casting the queries into the particular proposed tools.
  45.  
  46. The term "semantic benchmark"* has itself caused some controversy.  That's
  47. not surprising, since the juxtaposition of these two words was intended to
  48. have a certain dissonance, or at least unfamiliarity.  The intention is to
  49. cause people to stop and recognize that this is a different use of
  50. "benchmark" than they are accustomed to.
  51.  
  52. There was some discussion at SIGMOD that what we were doing was part of
  53. the "requirements specification" for TSQL, but we do not believe that the
  54. final product of our effort be required to meet something derived from
  55. these benchmarks.  First, the benchmarks are meant for evaluation and
  56. guidance, not as an absolute criterion.  Perhaps our use of "benchmark"
  57. harks back to the original use of the term, indicating a reference point.
  58. Second, as noted above, we could in fact do all of the queries in regular
  59. SQL, albeit with fragmented relations and convoluted WHERE clauses.
  60.  
  61. One difficulty with the benchmark effort as it is focused is that we have
  62. built an apparent self-contradiction into our task.  We have claimed that
  63. we are taking a high-level, user/meaning oriented approach but at the same
  64. time we have developed a taxonomy which is directed toward implementation.
  65. This in fact can be a valuable source of "creative tension" and expect
  66. that the most interesting class of queries will be those which do not fit
  67. into our taxonomy.  In this regard, Alex and Jim are right that we cannot
  68. claim that the benchmark is comprehensive.  We have no basis for
  69. justifying or even evaluating that.  Maybe "wide-ranging and inclusive"
  70. might be better.
  71.  
  72. Maybe it's too soon to be so grandiose with our expectations.  Our TSQL
  73. effort is likely to fall short of easy expression of all of the queries
  74. we develop.  But we should be aware of the deficiencies as well as
  75. the strengths.
  76.  
  77. In short, in spite of the problems, we're basically headed in the right
  78. direction.
  79.  
  80.                     Ed Robertson & Patrick Kalua
  81.  
  82. -------------------------------------------------------------------------
  83. * For those who do not have webster installed on their system, here's what
  84. it thinks of "bench mark" (only listed as two words) and "semantic."
  85.  
  86. bench mark n : a mark on a permanent object indicating elevation and 
  87.    serving as a reference in topographical surveys and tidal observations
  88.     [well at least the mention of tides gives one good hook for time]
  89.  
  90. se.man.tic \si-'mant-ik\ \-i-k*l\ \-k(*-)le-\ aj [Gk -se-mantikos 
  91.    significant, fr. se-mainein to signify mean, fr. (Xse-ma sign, token; akin 
  92.    to Skt dhya-ti he thinks 1: of or relating to meaning in language 2: of or 
  93.    relating to semantics - se.man.ti.cal aj
  94.